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INTRODUCTION 

This  paper  provides  an  overview  of  ASD's  Deputy  for 
Engineering  performance  oriented  business  approach,  more 
popularly  known  as  “Mil-Prime.”  The  development  of  Mil- 
Prime  specifications  and  standards  is  certainly  not  a  new 
subject  at  ASD.  What  is  new  is  the  integration  of  these 
tailorable,  performance  oriented  documents  with  the  System 
Engineering  Master  Schedule  concept,  enhanced  RFP  prepa¬ 
ration  activities,  and  a  streamlined  source  selection  process. 
The  effectiveness  of  these  activities  reflects  the  synergism  of 
this  corporate  business  approach. 

Mil’J!r.imeJg^£k&rmmd 

The  genesis  of  the  EN  Mil-Prime  program  goes  back  to 
the  late  70’s  and  was  in  response  to  some  very  high  level 
concerns  regarding  the  development  and  application  of  acqui¬ 
sition  specifications  and  standards.  A  1975  memo  from  the 
Deputy  Secretary  of  Defense  cited  the  blanket  application  and 
unbounded  sub-tiering  of  development  specifications  and 
standards  as  a  major  cost  driver  on  DoD  system  acquisition 
programs.  It  further  charged  that  the  DoD  acquisition  process 
did  not  include  adequate  checks  nor  process  controls  to  effect 
meaningful  application  of  these  documents.  On  the  heels  of 
the  DoD  memo  came  the  1977  Defense  Science  Board  report. 
It  included  the  straw  that  finally  broke  the  backs  of  the 
entrenched  specification  bureaucrats.  The  DSB  concluded 
that  the  blanket  application  of  layer  upon  layer  of  “design 
specifications”  represented  a  “bottom-up”  verses  a  “top- 
down”  process.  Rather  than  specifying  functional  needs,  the 
documents  dictated  design  solutions.  The  final  straw  was  their 
indictment,  and  rightly  so,  that  the  “bottom-up”  process  not 
only  failed  to  develop  systems  in  response  to  user  operational 
needs  but  it  also  was  inhibiting  technical  growth.  A  fresh 
approach  was  mandated. 

DoD  directed  that  a  complete  review  be  made  of  policies 
on  the  development  and  application  of  acquisition  documents. 
They  further  directed  that  implementation  policies  be  estab¬ 
lished  to  require  tailored  application  of  development  specifi¬ 
cations  on  all  new  system  acquisitions.  DSB  recommenda¬ 
tions  went  further  in  that  they  addressed  other  crucial  and 
fundamental  factors  such  as: 

I)  Strengthening  the  process  by  which  user  operational 
needs  arc  actually  translated  into  system  design  requirements. 


2)  Rcformating  military  design  specifications  to  make 
the  mandated  tailoring  process  “user  friendly”  and  under¬ 
standable. 

There  were  no  sacred  cows  in  the  DSB  recommendations. 
They  went  so  far  as  to  suggest  the  use  of  “Commercial” 
specifications  and  standards  on  military  programs,  a  concept 
the  bureaucrats  considered  to  be  blasphemy. 

Over  the  years  two  situations  developed  in  the  evolution 
of  development  specifications: 

1)  “Design  Solution”  requirements  began  creeping  in. 

2)  “Lessons  Learned”  which  represented  the  DoD  cor¬ 
porate  history  were  being  assimilated  into  these  design  solu¬ 
tion  requirements. 

This  continued  because,  in  many  instances,  the  specification 
of  design  solutions  by  the  government  proved  to  be  successful 
from  a  performance  standpoint.  However,  development 
specifications  evolved  to  the  point  that  they  constrained  the 
use  of  other  effective  design  solutions.  While  “Lessons 
Learned”  proved  to  be  an  effective  tool  in  reducing  the 
government’s  risk,  they  to  often  resulted  in  all  available 
specifications  being  imposed  in  the  attempt  to  cover  all 
contingencies.  This  resulted  in  the  generation  of  RFPs  with 
hidden  problems  and  massive  document  tiering.  The  specifi¬ 
cation  of  production  type  requirements  or  overspecified  gen¬ 
eral  requirements  were  also  resulting  in  single  design  solu¬ 
tions.  In  short,  too  much  guidance  stifled  innovative  design 
solutions  and  restricted  competition. 

The  ASD  program  went  back  to  basics  to  upgrade 
development  specifications  and  standards  used  in  the  ASD 
acquisition  process.  As  reflected  in  Figure  1,  the  change 
required  moving  from  “How  To”  documents  to  “Perform¬ 
ance”  oriented  documents.  The  approach  had  to  insure  that 
acquisition  documents  communicated  the  performance  char¬ 
acteristics  of  the  product  the  user  needed  and  that  only  appro¬ 
priate  specifications  and  standards  were  referenced  therein. 
The  goal  was  to  prepare  “program  tailorable”  development 
documents  that  would  permit  innovative  design  solutions.  In 
retrospect,  the  EN  response  to  these  directives  and  recommen¬ 
dations  was  actually  pretty  straight  forward  —  not  easy,  but 
nevertheless  straight  forward. 


987 

U.S.  Government  work  not  protected  by  U.S.  copyright- 


As  shown  in  Figure  2,  the  ASD  Mil-Prime  philosophy 
was  to  prepare  generic  development  documents  that  repre¬ 
sented  the  best  starting  point  for  tailoring  to  specific  program 
applications.  These  documents  would  state  generic  perform¬ 
ance  parameters  with  specific  values  left  blank.  There  would 
be  a  1  to  1  correlation  of  Section  3  Requirements  to  Section  4 
Verification.  Another  mandatory  requirement  was  to  reduce 
the  number  of  referenced  specifications.  The  documents 
would  also  retain  the  DoD  corporate  history  in  a  non-contrac- 
tual  “Lessons  Learned”  appendix  handbook  to  assist  in  the 
tailoring  process  for  program  specific  applications.  At  the 
start  of  the  initiative,  there  were  some  47,000  active  DoD 
speeifieations  and  standards.  Of  that  number,  43,000  were 
procurement  related  with  about  4,000  used  for  development. 
Of  the  4,000  development  documents,  500  were  in  some  use 
by  ASD  with  about  50  -  60  being  frequently  used  on  major 
system  acquisitions. 

The  scope  of  the  task  was  doable. 


The  “Update”  of  over  50  major  ASD  acquisition 
documents  has  been  completed  to  conform  with  the  Mil- 
Prime  philosophy.  In  fact,  a  number  arc  already  through 
their  second  revisions.  The  Landing  Gear  Mil-Prime 
provides  a  typical  example  of  the  reduction  in  specifica¬ 
tions  tiering.  Prior  to  Mil-Prime,  there  were  13  different 
landing  gear  specifications  which  in  turn  referenced  256 
other  documents.  There  is  now  only  1  specification,  Mil- 
L-87139,  which  references  2  other  documents.  Unfortu¬ 
nately  there  is  limited  interest  in  the  Mil-Prime  approach 
from  otherU.S.  Services.  The  British  M  inistry  of  Defense, 
however,  has  stated  that  there  is  a  positive  interest  in 
developing  aerospace  “Europrimes.”  The  EN  experience 
shows  that  the  executive  level  at  large  Air  Force  prime 
contractors  accept  the  approach.  However,  quite  a  few  of 
their  mid-level  working  managers  and  engineers  do  not. 
The  experience  at  ASD  is  similar,  but  the  course  of  the 
bureaueraey  continues  to  be  altered. 

System  Guide  Specification 

The  most  recently  completed  Mil-Prime  document  is  the 
System  Specification,  AFGS-87253,  completed  under  the 
DoD  guide  specification  initiative  approved  in  Nov  1986.  The 
fundamental  objectives  of  this  System  Level  Mil-Prime  are  to 
provide  consistent  guidance  for  the  translation  and  appl  ication 
of  validated  User  operational  needs,  via  the  AFR  57-1  process, 
into  system  level  design  requirements  that  are: 

1)  Meaningful  to  meeting  user  operational  needs. 

2)  Measurable  during  design  development  and  test. 

3)  Achievable  in  performance,  eost  and  schedule. 

4)  Maintainable  per  the  User  support  strategy. 

The  critical  challenge  that  developers  of  system  specifications 
face  is  to  accurately  communicate  the  system  characteristics 
of  the  product  the  user  needs  including  affordability,  main¬ 
tainability,  and  supportability.  Thus,  AFGS-87253  places 
strong  emphasis  on  the  Systems  Engineering  Approach  to 
design  development.  The  “Upfront”  integration  of  system 
issues  such  as  support,  maintenance,  manpower,  training, 
etc.,  is  emphasized  to  make  them  proactive  with  the  system 
engineering  analysis,  synthesis,  and  tradeoff  process.  Fun¬ 
damental  to  this  process  is  the  disciplined,  top-down  flow 
of  user  operational  needs  into  the  level  2and  3  tailored  Mil- 
Prime  specifications,  thereby  evolving  a  synergistic  set  of 
tailored  development  specifications. 

Bureaucrats  would  probably  say  that  AFGS-87253  is 
not  in  conformance  with  Mil-Std490A,  Specification 
Practices,  because  it  does  not  follow  the  uniform  para¬ 
graph  numbering  requirements.  The  System  Mil-Prime 
was  developed  on  a  higher  plane  to  emphasize  the  more 
essential  requirements  of  Mil-Std-490A  for  system  speci¬ 
fications  to: 

1)  Properly  state  technical  performance  and  opera- 


•  Emphasize  Performance  Requiremenls 

✓  Define  Performance  Parameters 

✓  Leave  Specific  Values  Blank 

•  1  To  1  Correlation  Of  Requiramanl  To  Verification 

•  Reduce  Number  Of  Refarancas 

•  Retain  "Lessons  Laarned"  In  A  Non>Contractual 
Appendix  To  Assist  In  Tailoring 


Figure  2  -  Mii-Prime  Philosophy 
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tional  mission  requirements  from  the  total  system  employ¬ 
ment,  deployment,  operational,  support,  and  maintenance 
perspective. 

2)  Require  the  upfront  identification  of  system  level 
interfaces  between  and/or  among  all  functional  areas. 

3)  Properly  allocate,  within  system  design  constraints, 
the  system  level  performance  requirements  to  functional 
areas. 


As  shown  in  Figure  3  and  Figure  4,  the  system  guide 
specification  does  follow  traditional  format  regarding  Scope. 
Applicable  Documents.  Requirements,  yerificatiQD,  Prepara¬ 
tion  for  Delivery,  and  Note  Sections.  There  are,  however,  a 
number  of  unique  features.  They  are: 

1)  Specifying,  in  Section  3  Requirements,  the  intended 
scenario  and  mission  descriptions  against  which  the  system 


1  0  SCOPE. 

1  1  IDENTIFICATION, 

1.2  APPLICATION. 

1.3  INTRODUCTION 

2.0  APPLICABLE  DOCUMENTS 

21  GOVERNMENT  DOCUMENTS 

22  ORDER  OF  PRECEDENCE. 


3  1  5  Operalcnal  Eftedrvonet* 
3  15  1  Availability 
3  1.52  Operational  Availability 

3.1.5  3  Mi««on  Rdiabbty 

3.1  6  SyfJams  Interlace* 

3.1.6  1  Internal 
3  162  External 


3  0  REQUIREMENTS 

31  MISSION  OPE  RATIONAL 
PERFORMANCE. 

3.11  Scenarios.  Operafcnal 
Concept*  And 

Support  Concept* 

3.1.2  Mwakxt  Description* 

3.1.2  1  Deployment  Requtements 

3.1.3  Mi**ion  Level  Constraint*. 

3.1.4  Environment 
3.1.41  Naturd 

3. 1.4.2  Induced. 

3. 1.4. 3  Threat 


3.1.7  Supportably. 

3  17  1  System  Maintainability. 

3.1.7  2  Manpower  and  Personnel. 

3.17  3  Maintenance  System. 

3  1.74  Training  Support 

317  5  Support  Of  Computer  Resource* 

3.1  7  6  Fealties 

3.1  7.7  Packaglng/Handling/Storage/Tranap 
3  17  6  Battle  Damage  Repair 

3.1.6  Operational  Service  Lite. 

3  2  SYSTEM  DESCRIPTION 

3.2.1  System  Element* 
a  Air  Vahid* 

b  Integrated  SuppoM  System 
c.  Training  System 


Figure  3  *  AFGS-87253  Contents 


power,  personnel,  training,  safety,  et  cetera. 

The  Design  and  Construction  Section  guidelines  focus 
on  tailoring  system  design  criteria  that  are  applicable  to  all 
elements  of  the  system.  For  Example: 

1)  System  level  computer  software  requirements  per¬ 
taining  to  system  architecture,  computer  language,  software/ 
hardware  interfaces,  et  eetera. 

2)  System  level  requirements  for  use,  control,  and  dis¬ 
posal  of  hazardous  materials  for  all  aspects  of  operation, 
maintenance,  and  training. 

The  basie  objectives  of  Section  4  Verification  are  to 
define  the  various  demonstrations,  tests,  methods  of  verifica¬ 
tion,  etc.,  whieh  will  be  utilized  to  verify  quality  conformanee 
to  Section  3  system  requirements.  As  seen  in  Figure  4,  AFGS- 
87253  also  reeognizes  that  process  eontrol  may  be  an  appro¬ 
priate  verification  alternative  for  rate  production.  Such 
verification  would  only  be  used  after  the  integrated  set  of 
system  elements  have  met  all  qualification  criteria  and 
have  demonstrated  full  eomplianee  with  the  requirements 
of  Section  3.  Section  4.2  provides  guidance  and  illustra¬ 
tions  for  defining  in-process  (during  design  development) 
verification  requirements,  if  appropriate.  The  intent  of  this 
type  of  verification  requirement  is  to  track  progress  of 
design  eomplianee  with  key  Section  3  system  require¬ 
ments.  In-process  verification  requirements  would  be 
based  on  key  system  engineering  activities  that  are  deemed 
critical  to  successfully  meeting  the  selected  Section  3 
system  requirements.  Technical  Performance  Measure¬ 
ment  (TPM)  tracking  parameters,  including  tolerances, 
must  likewise  be  established  for  those  selected  activities. 
The  tracking  parameters  must  be  measurable  by  accept¬ 
able  technical  practices ,  e.g.,  analysis,  simulation,  tests,  et 


level  requirements  are  defined  for  both  peacetime  and  war¬ 
time  operations.  Under  Mil-Std490A  these  descriptions 
would  be  included  in  the  noncontractual  Section  6  Notes. 

2)  Expressing,  at  the  system  level,  operational  re¬ 
quirements  in  User  oriented  terms  which  define  quantita¬ 
tive  requirements  for  military  utility.  Measures  of  merit 
are  used  as  criteria  to  assess  operational  utility.  For 
example:  ton-miles  per  day,  tank  kills  per  sortie,  et  eetera. 

3)  Defining  all  internal  and  external  interfaces  with 
other  systems,  equipments,  operations,  training,  deploy¬ 
ment  environments,  et  eetera. 

4)  Providing  guidance  for  in-process  verification 
requirements. 

The  Seetion  3.1.7  Supportabilitv  requirements, 
based  upon  the  requirements  of  Sections  3.1.1  through 
3.1.6,  must  reflect  compatibility  with  items  that  affect  the 
readiness/availability  of  the  system;  e.g.,  the  number  of 


3  2.2  Design  And  Con* ruction. 

322  1  Computer  Resources. 

4.2  N  PROCESS  VERIFICATION  MEASUREMENT 

3  2  2-2  Common  Sy*  Characteristic*. 

3.2.23  Standard  z  Hon. 

43  QUALITY  CONFORMANCE. 

3.2.2  4  Nameplate  s/Product  Markings 

43.1  MissJorVOperabonai  Performance 

3-225  Produd  bitty 

43.2  System  Description. 

3-22.6  Workmanship 

3.2  2  7  System  Safely. 

4  4  RESPONSIBILITY  FOR  CONTROL 

3 2  21  Nud ear  Contoi  Requramants 

OF  PROOUCT  OUALITY. 

3.2.2  6  Corr/Mat  DegradHon  Re*. 

4.4.1  Responsibitty  For  Conformance 

3.2.2  10  Etectomagnelic  Compatibly 

4  4.2  Responsibly  For  Venftcabon. 

3.2.2  11  Human  Factors 

3.2  2  12  Hazardous  Materites 

3  0  PREPARATION  FOR  DELIVERY 

33 PRECEDENCE 

6.0  NOTES. 

40  VERIFICATION 

4  t  GENERAL 

8  1  APPENDIXES 

4  1  1  Tesl  Requir  amenta  Variftcaton 

6 2  REFERENCE  DOCUMENT  TREE 

4,1.11  Full  Scale  Engr  Dev  Tesl  Program 

6  3  SUBJECT  TERMS  (Key  Words) 

4  1.12  Spedat  Tests. 

6.4  RESPONSIBLEENGMEERINGOFFICE 

41.2  Methods  01  Verification 

a  Inspection 
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b  Analysis 

APPENDIX  B  Detentions 

C  Demonsfrafon 

APPENDIX  C  SEMS  (Exwnple) 

d  Test 

APPENDIX  D  •  Sample  System  Specification 

•  Process  Contoi 

Figure  4  -  AFGS-87253  Contents  (Cont) 


systems,  system  diagnostics  and  testability,  fault  tolerance,  eetera..  Measures  sueh  as  “percent  complete”  are  usually  ar- 

employment  related  requirements,  battle  damage  repair,  man-  bitrary  and  misleading  and  should  be  avoided.  The  following 
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arc  examples  of  in-process  verification  requirements: 

“4.2.X  Development  of  required  Interface  Control 
Documents  (ICDs)  shall  be  verified  by  a  combination  of 
inspection,  analysis,  and/or  laboratory  demonstrations. 
Compliance  with  the  internal  and  external  system  interface  re¬ 
quirements  specified  in  3.1.6. 1  and  3. 1.6.2  must  be  demon¬ 
strated.  ICDs  are  considered  complete  when  details  of  the 
required  interface  testing  are  specified  in  applicable  detailed 
test  plans." 


ment  risks  for  input  to  program  management.  It  requires 
upfront  planning  and  integration  to  identify  and  reach  contrac¬ 
tor  and  program  office  agreement  on  key  system  engineering 
tasks.  Figure  5  illustrates  the  prime  objective  of  a  SEMS  is  to 
improve  the  technical  integrity  of  the  development  program 
by: 

1)  Reducing  development  risks. 

2)  Instilling  design  discipline. 

3)  Providing  event  oriented,  progress  based  decision 
criteria. 


"4.2. Y  System  engineering  integration  of  User  sup- 
portability  requirements  defined  in  3. 1.7.1  through  3. 1.7.8 
shall  be  validated  by  analysis,  trade  studies,  etc.,  during 
FSED.” 

Seetion  4.3,  Quality  Conformance,  is  intended  to  specify  the 
method(s)  of  verification  for  each  Seetion  3  system  require¬ 
ment 

As  an  additional  aid  to  developers  of  system  specifica¬ 
tions,  the  guide  specification  also  includes  four  appen¬ 
dixes  which  provide : 

1)  An  illustration  of  appropriate  definitions  of  test 
requirements  and  methods  to  preclude  misinterpretationof 
seetion  4  verification  requirements. 

2)  Definitions  of  terms  used  within  the  guide  speci¬ 
fication. 

3)  A  simplified  discussion  of  the  System  Engineer¬ 
ing  Master  Schedule  concept. 

4)  A  sample  system  specification  to  further  illus¬ 
trate  the  application  guidelines. 

Systems  Engineering  Master  Schedule 

The  Mil-Prime  business  approach  extended  beyond 
just  the  need  to  eliminate  development  documents  that  in¬ 
cluded  unconstrained  specification  sub-tiering  which  in 
turn  constrained  design  solutions.  The  corporate  business 
approach  also  needed  to  embrace  an  environment  which 
fostered: 

1)  Flexibility  in  system  engineering  management 
approaches. 

2)  Innovation  in  pursuit  of  design  solutions  to  best  meet 
user  operational  needs. 

This  fresh  approach  does  not  abrogate  fundamental  require¬ 
ments  for  team  planning  and  development  of  meaningful 
measures  of  merit  to  traek  design  progress.  The  Systems 
Engineering  Master  Schedule  (SEMS)  coneept,  the  keystone 
of  our  Mil-Prime  performance  oriented  business  approach, 
provides  a  disciplined  approach  for  accomplishing  these  basie 
system  management  functions.  The  SEMS  eoneept  provides 
an  improved  framework  to  guide  the  interface  with  the  con¬ 
tractor  in  assessing  technical  progress  and  associated  de velop¬ 


When  implemented  on  a  program,  SEMS  provides  a  contrac¬ 
tual,  technical  events  oriented  “schedule.”  It  identifies  key 
system  engineering  tasks,  their  interrelationships  with  the 
program  milestones  and  schedule,  and  the  speeifie  criteria  to 
be  utilized  to  track  and  measure  successful  task  completion. 
The  successful  completion  of  the  identified  tasks  and/or  risk 
reduction  activities  is  requisite  to  passing  design  decision 
points,  program  decision  milestones,  and/or  eontraet  demon¬ 
stration  milestones.  The  SEMS  is  developed  by  the  contrac¬ 
tor,  delivered  wi  th  his  proposal,  negotiated  with  other  contrac¬ 
tual  documents  if  required,  and  generally  implemented  as  a 


•  Systems  Engineering  MasteJiSchg&?te  -  A  Contractual 
Technical  Events  Schedule  Which  Identifies  Technical 
Tasks  That  Must  Be  Successfully  Completed  To  Pass 
Identified  Technical  Demonstration  Milestones 

✓  The  SEMS  Is  Developed  By  The  Contractor 

✓  Delivered  With  The  Proposal 

✓  Negotiated  During  Source  Selection 

✓  Impiemented  As  A  Conlractuai  Annex  To  The  SOW 

•  Provides  Quantitative  Technical  Input  Into  Program 
Decision  Points 


Figure  5  -  SEMS  What  Is  It? 

contractual  annex  to  his  statement  of  work. 

The  SEMS  eoneept  also  enhances  the  team  approach  to 
integrated  product  development.  It  provides  the  upfront 
planning  and  integration  to  define  all  diverse  specialty  tasks 
and  events  that  must  be  successfully  completed  to  meet  user 
needs.  It  also  provides  the  top-to-bottom  traeeability  from 
user  needs,  through  the  statement  of  work  task  definitions, 
through  the  tailored  Mil-Prime  specifications,  and  ultimately 
to  the  integrated  system  development  activities.  The  negoti¬ 
ated  SEMS  is  a  critical  risk  management  tool.  When  tied  to 
technical  reviews  and  program  demonstration  milestones,  it 
provides  the  objective  yardsticks  that  focus  on  the  accom¬ 
plishment  of  critical  development  tasks  and  the  quality  or 
sueeess  of  their  execution.  The  ASD  Commander  has  directed 
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that  Acquisition  Strategy  Panels  and  Acquisition  Review 
Teams  address  the  use  of  SEMS  along  with  proposed  demon¬ 
stration  milestones  on  all  new  ASD  development  programs. 

Some  examples  of  technical  tasks  that  might  be  candi¬ 
date  activities  for  a  SEMS  are  reflected  in  Figure  6.  This 
example  is  in  no  way  intended  to  serve  as  a  checklist.  It  merely 
illustrates  some  of  the  tasks  and  events  that  would  likely  have 
to  be  successfully  accomplished  to  pass  a  particular  milestone. 
Typical  guidance  can  be  found  in  guidance  documents  such  as 
Mil-Std-1521B.  Technical  Reviews  And  Audits  For  Systems. 
Equipments.  And  Computer  Software.  The  requirement  for 
an  integrated  team  approach  is  visibly  reflected  by  the  wide 
variety  of  tasks.  A  properly  developed  SEMS  will  reflect  the 
interrelationships,  interfaces,  etc.,  required  by  all  members  of 
the  development  team:  hardware  and  software  design  en¬ 
gineers;  supporters  and  maintainers;  integrated  test  team; 
manufacturing;  cost/schedule  personnel;  et  cetera. 


Assume  one  is  developing  a  system  that  includes  an 
air  vehicle  as  one  of  its  major  elements.  User  operational 
requirements,  in  turn,  require  some  sort  of  a  landing  gear 
subsystem  —  not  what  type ,  though !  The  program  tailored 
Work  Breakdown  Structure  (WBS)  Dictionary  would 
identify  a  statement  of  work  paragraph  which  includes  the 
tasking  to  design,  develop,  and  qualify  a  landing  gear  sub¬ 
system.  The  Instructions  To  Offerors  (ITO)  portion  of  the 
Request  For  Proposal  would  have  related  text  that  might 
read  something  like:  “The  SEMS  shall  include  all  the 
major  events  and  associate  success  criteria  which  address 
the  design  process  for  each  major  element  of  the  landing 
gear  subsystem,  its  integration  into  the  air  vehicle,  and  its 


(tasks,  events,  etc.)  such  as  developing  the  preliminary  design 
definition,  new  materials  characterizations  required,  compo¬ 
nent  testing  to  be  accomplished,  hardware  qualifications,  etc., 
and  their  relation  to  specific  contractual  events  and  milestones 
such  as  PDR  and  CDR  would  be  defined.  The  criteria  and 
metrics  to  be  used  to  measure  and  track  design  progress  to 
successful  completion  of  each  specified  task  would  be  clearly 
defined  in  related  text.  Additional  non-eontraetual  detail,  at 
the  next  level  of  indenture,  might  also  be  presented.  It  might 
reflect  tasks  fundamental  to  completion  of  a  landing  gear 
preliminary  design  (the  S  OP  systems  engineering  stuff).  S  uch 
information,  while  not  contractual,  would  provide  further 
insight  into  the  contractor's  planned  development  activities 
and  his  level  of  day-to-day  design  development  progress 
tracking.  Various  interfaces  and  reviews  that  are  planned  at 
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Figure  7  -  SEMS  Contractual  Tasks 
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Figure  6  -  Example  Technical  Tasks 

interfaces  with  other  system  elements.” 

The  contractor's  proposed  SEMS  might  have  a  tabular 
format  similar  to  Figure  7.  Significant  accomplishments 


the  subcontractor  and  vendor  might  also  be  shown. 

There  is  no  prescribed  best  method  to  document  a 
SEMS.  Figure  8  depicts  another  approach.  In  this  case  a 
“waterfall”  diagram  is  used  to  present  the  task  activities 
(circles)  that  must  be  successfully  completed  prior  to  each 
Demonstration  Milestone  (triangle)  to  make  informed  pro¬ 
gram  decisions.  The  details  of  the  progress  measurement 
and  success  criteria  for  each  contractual  SEMS  task  would 
be  defined  in  related  contractual  documents.  A  key  point 
to  mention  here  is  that  the  “date”  for  completion  of  individ¬ 
ual  tasks/events  is  not  the  critical  factor.  The  critical 
measure  is  the  successful  completion  of  all  the  identified 
activities  prior  to  stepping  through  the  Demonstration 
Milestone.  The  SEMS  must  provide  adequate  details  to 
show  the  interrelationships  of  the  milestones  and  task 
schedules  and  it  must  be  the  basis  for  all  subsequent 
detailed  planning.  All  supporting  plans  (Integrity  Master 
Plan,  Software  Development  Plan,  System  Test  Plan,  etc.) 
and  each  development  specification  Section  4  verification 
task  must  be  supportive  of  and  consistent  with  the  SEMS  and 
the  Statement  of  Work. 
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REf  s  and  Source  Selection 

There  have  been  many  articles  of  recent  which  address 
a  wide  variety  of  issues  as  they  pertain  to  a  very  complex 
acquisition  process.  One  must  not,  however,  lose  sight  of  the 
Govemment/Industry  team  bottom  line  in  that  process.  The 
bottom  line  of  that  partnership  is  to  develop,  produce,  and  field 
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Figure  8  -  Another  Approach 

the  most  cost-effective  weapons  systems  possible  which  meet 
the  User’s  operational  needs.  The  individual  contractor  tailor¬ 
ing  of  the  generic  Mil-Prime  documents  and  development  of 
SEMS  that  are  unique  to  their  design  approach  encourage 
innovation  and  avoid  technical  leveling.  Recent  dialogue  with 
industry,  however,  indicates  there  are  some  misconceptions 
regarding  streamlined  source  selection  activities.  A  funda¬ 
mental  motive  of  recent  legislation  and  AFSC  policy  is  to 
emphasize  the  importance  of  pre-source  selection  and  draft 
RFP  Govemment/Industry  discussions.  The  objectives  of 
early  discussions  arc  to  reduce  proposal  preparation  and 
evaluation  time  by  improving  the  quality  of  proposals  and 
efficiency  of  the  evaluation  process. 


Figure  9  -  Historical  Perspective 


A  perspective  of  past  Air  Force  RFP  preparation  and 
source  selection  process  activities  is  depicted  in  Figure  9.  It 
is  inherent  behavior  of  engineers  to  deal  in  details. ..dot  all  the 
“Is”  and  cross  all  the  “Ts”... leave  nothing  to  chance  or  as¬ 
sumption.  That  is,  of  course,  exactly  what  was  done.  The  Air 
Force  side  of  the  development  team  actually  wrote  the  de¬ 
tailed,  product  oriented  specifications.  They  prepared  the 
text  for  the  technical  portions  of  the  Statement  Of  Work, 
told  bidders  what  documentation  was  required,  and  even 
provided  a  Model  Contract  Not  bad.. ..if  you  were  on  the 
proposing  side  of  the  equation.  As  any  sane  bidder  would 
do,  they  all  said  “Yea,  we  can  do  that.”  In  essence,  they  ran 
the  Air  Force  RFP  through  the  copy  machine  and  only  had 
to  prepare  their  cost  and  technical  proposals.  Perhaps  an 
exaggeration  to  make  a  point  but  in  a  global  sense  not  far 
from  the  truth  either.  The  unfortunate  results  of  this 
approach  were  technical  leveling  and  limited  contractor 
innovation.  Additionally,  it  left  limited  information  upon 
which  to  award  the  contract...  a  cost  proposal  and  a 
technical  brochure.  Not  the  optimum  information  for  se¬ 
lecting  the  proposal  which  would  best  meet  user  needs 
with  minimal  development  and  production  risk.  A  better 
approach  was  certainly  needed  to  provide  bidding  contrac¬ 
tors  the  opportunity  to  really  propose  design  solutions  that 
reflected  their  capabilities. ..good  or  bad. 

Figure  10  depicts  the  current  Mil-Prime  approach  to 
RFPs  and  Source  Selections.  It  emphasizes  the  “DRAFT 
RFP”  which  includes:  a  Technical  Requirements  Document 
(TRD);  Instructions  To  Offeror  (ITO);  Evaluation  Factors  for 
Award;  and  the  frameworks  for  a  Model  Contract  and  Con¬ 
tract  Data  Requirements  List  (CDRL).  As  noted  earlier,  the 
objectives  of  this  approach  are  to  improve  the  quality  of 
contractor  proposals  and  the  efficiency  of  the  evaluation 
process.  The  cornerstone  for  attaining  these  objectives  is  pre- 
source  selection  discussion  with  timely  and  effective  govem- 
ment/industry  dialogue  on  the  draft  RFP.  Eaeh  and  every  one 
of  the  bidding  eontraetors  must  have  the  opportunity  to 
submit  their  best  proposal  the  first  time.  This,  of  course, 
requires  a  sound  understanding  of  user  needs,  system  op¬ 
erational  requirements  and  constraints,  and  the  evaluation 
factors  to  be  utilized  for  award.  Bidders  can  than  tailor 
those  Mil-Prime  speeifieations  applicable  to  their  design 
approach,  develop  their  System  Engineering  Master 
Schedule,  et  cetera.  They  are  afforded  the  opportunity  to 
provide  the  quality  information  necessary  to  accurately 
reflect  their  unique  design  approach  and  to  improve  the  ef¬ 
fectiveness  of  the  source  selection  team.  The  Air  Force 
evaluation,  using  the  technical  volume  as  a  guide,  will 
focus  on  the  proposed  contractual  documents  as  prescribed 
in  the  “Factors  for  Award”  section  of  the  RFP.  These 
documents  define  the  offeror’s  corporate  commitment  to 
developing  and  fielding  a  system  that  will  meet  user  needs 
and  operational  requirements. 
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Figure  10  -  Current  Perspective 


The  Technical  Requirements  Document  (TRD)  is 
prepared  by  the  System  Program  Office  and  issued  as  part  of 
the  RFP.  It  has  a  mission/operational  orientation  (per  the 
System  Operational  Requirements  Document  and  Statement 
of  Need)  and  only  references  first  tier  requirements.  It  covers 
the  entire  system,  ie.,  prime  mission  equipment,  training  sys¬ 
tem  ,  support  system,  et  cetera.  The  TRD  follows  the  “Section” 
categories  in  AFGS-87253  and  is  to  be  used  by  the  offeror  to 
prepare  their  proposed  system  specification. 

The  Instructions  To  Offerors  (ITO),  Section  L  of  the 
RFP,  provides  concise,  and  complete  direction  to  the  offeror 
regarding  developing  their  SOW,  SEMS,  Specifications, 
CDRL,  etc.,  which  must  clearly  define  their  proposed  design 
approach.  It  identifies  topics  the  offeror  must  provide  and 
discuss;  e.g.,  integrity  program  tailoring,  design  integration  of 
system  supportability,  manufacturing,  maintainability,  man¬ 
power,  personnel,  training,  diagnostics  issues,  et  cetera. 

The  Evaluation  Factors  For  Award,  Section  M,  pro¬ 
vides  definition  of  specific  criteria  and  key  performance  para¬ 
meters  to  be  assessed  during  source  selection.  Basic  criteria 
would  include  understanding  the  operational  needs,  sound¬ 
ness  of  design  approach,  and  compliance  wi  th  system  require¬ 
ments. 

The  Model  Statement  Of  Work  (SOW)  provides  the 
fundamental  program  framework  and  outline  of  top-level 
tasking.  The  offeror  must  expand  this  framework  with  de¬ 
tailed  task  descriptions  appropriate  to  their  design  approach. 

The  Model  Contract  Data  Requirements  List 
(CDRL)  would  define  the  minimum  data  needed  to  conduct 
the  program  and  require  general  access  to  contractors  working 
data. 

As  emphasized  in  the  ITO,  the  source  selection  technical 


evaluation  and  rating  will  be  based  primarily  on  the  infor¬ 
mation  contained  in  the  proposed  contractual  documents. 
The  technical  volume  will  be  used  as  a  guide  to  under¬ 
standing  the  offeror’s  design  approach  and  as  a  roadmap  to 
locate  definitized  activities  within  the  proposed  contrac¬ 
tual  documents.  The  contractor’s  proposed  activities  to 
design,  develop,  produce,  and  field  the  entire  system  will 
be  definitized  in: 

1)  The  specifics  of  integrated  tasking  proposed  in 
the  SOW. 

2)  The  proposed  SEMS  key  tasks  and  measurement 
criteria  for  completing  each  proposed  majorprogram  mile¬ 
stone. 

3)  The  system  specification  that  establishes  the 
functional  baseline  which  meets  the  TRD,  how  those  re¬ 
quirements  will  be  verified,  and  the  flowdown  of  those  re¬ 
quirements  into  subsystem  and  prime  item  development 

specifications. 

4)  The  proposed  CDRL,  availability  and  access  to  con¬ 
tractor  design  decision  data,  and  sub-contractor  information. 

5)  The  recurring  and  non-recurring  engineering  activi¬ 
ties  which  form  the  basis  for  the  technical  portion  of  the 
offeror’s  cost  proposal. 

A  lot  of  subjects  and  their  integrated  use  in  system 
development  activities  at  ASD  have  been  presented.  A  review 
of  the  key  features  of  each  element  might  be  helpful. 

The  Deputy  for  Engineering  Mil-Prime  approach  to 
generation  of  specifications  and  standards  embraces  a  devel¬ 
opment  orientation  vis-a-vis  a  product  orientation.  The  prod¬ 
ucts  attained  are  generic  acquisition  documents  that  represent 
a  best  starting  point  for  tailoring  development  documents  to  a 
specific  program  application.  The  tailored  documents,  in  turn, 
reflect  the  performance  characteristics  of  the  product  the  User 
needs  to  satisfy  his  operational  needs.  The  Mil-Primes  also 
encourage  innovative,  multiple  design  solutions  from  bidding 
contractors  while  controlling  tiering  of  reference  documents. 
A  most  important  feature  of  these  documents  is  the  one-to-one 
correlation  of  measurable  verification  procedures  for  each 
Section  3  requirement.  The  DoD  and  Industry  corporate 
histories  have  been  retained  in  a  non-contractual  “Lessons 
Learned”  appendix  handbook  to  assist  in  the  tailoring  process 
for  program  specific  applications. 

AFGS-87253  provides  basic  format  and  content  guid¬ 
ance  to  developers  of  system  specifications  for  translating 
User  needs  into  operational  performance  requirements.  The 
translation,  via  the  AFR  57-1  process,  is  structured  to  User 
operational  needs,  operational  environments,  system  integrity 
requirements,  and  system  constraints.  The  translated  user 
needs  must  be:  measurable  during  design  development  and 
test;  achievable  in  terms  of  performance,  cost,  and  schedule; 
and  maintainable  per  the  support  and  maintenance  strategy. 
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The  document  reflects  strong  emphasis  to  make  all  elements 
of  User  requirements  (resources,  training,  operation,  mainte¬ 
nance,  and  support)  proactive  with  the  system  engineering 
analysis,  synthesis,  and  trade-off  process.  In  addition  to  basic 
Section  4  objectives  to  define  the  methods  which  will  be 
utilized  to  verify  conformance  to  Section  3  system  require¬ 
ments,  Section  4.2  affords  the  opportunity  for  in-process 
measurement  and  tracking  of  critical  Section  3  requirements. 
Selected  parameters  are  tracked  with  key  System  Engineering 
Master  Schedule  tasks  and  risk  reduction  activities  that  are 
deemed  critical  to  successfully  meeting  the  selected  system 
requirements. 

The  Systems  Engineering  Master  Schedule  Concept 
enhances  integrated  product  development  via  the  system 
engineering  process.  It  provides  a  d  isciplined,  integrated  team 
approach  to  up-front  technical  planning,  to  development  of 
meaningful  measures  of  merit,  and  to  tracking  of  design 
progress  toward  satisfying  system  requirements.  The  prime 
objectives  of  SEMS  are  to: 

1)  Minimize  development  risks. 

2)  Instill  balanced  design  discipline. 

3)  Provide  management  with  event  oriented,  progress 
based  criteria  for  making  informed  decisions. 

4)  Improve  the  technical  integrity  of  development  pro¬ 
grams. 

The  SEMS  is  that  critical  risk  management  tool  that,  when  tied 
to  technical  reviews  and  program  demonstration  milestones, 
provides  the  objective  yardsticks  that  focus  on  the  accom¬ 
plishment  of  critical  development  tasks  and  the  quality  or 
success  of  their  execution.  It  is  developed  by  the  contractor, 
delivered  with  his  proposal,  negotiated  with  other  contractual 
documents,  and  generally  implemented  as  acontractual  annex 
to  his  statement  of  work.  The  ASD  Commander  has  directed 
the  development  and  use  of  SEMS  along  with  proposed 
demonstration  milestones  on  all  new  ASD  development  pro¬ 
grams. 

The  objectives  of  enhanced  RFP  and  Source  Selection 
activities  are  to  reduce  proposal  preparation  and  evaluation 
time  by  improving  the  quality  of  proposals  and  efficiency  of 
the  evaluation  process.  The  cornerstone  for  accomplishing 
these  objectives  is  pre-source  selection  discussion  with  effec¬ 
tive  Govemment/Industry  dialogue  on  the  draft  RFP.  A 
sound,  complete  understanding  of  User  needs,  system  opera¬ 
tional  requirements  and  constraints,  and  the  evaluation  factors 
to  be  utilized  for  award  must  be  shared  by  all  team  members. 
The  Air  Force  evaluation,  using  the  technical  volume  as  a 
guide,  will  focus  on  the  proposed  contractual  documents 
which  define  the  offeror’s  corporate  commitment  to  develop¬ 
ing  and  fielding  a  system  that  will  meet  User  needs  and 
operational  requirements.  The  technical  evaluation  will  as¬ 
sess  the  contractor’s  proposed  design  approach  to  meeting  key 


system  performance  parameters  as  discussed  in  the  Instruc¬ 
tions  to  Offerors.  The  submittal  of  quality  proposals  may  very 
well  preclude  the  necessity  to  “negotiate”  with  multiple  bid¬ 
ders  during  the  source  selection  process.  To  be  able  to  award 
without  discussion  is  an  admirable  goal  and  would  be  a 
splendid  testimonial  to  the  quality  of  a  contractor’s  proposal. 

Summary 

The  synergistic  effect  of  the  corporate  integration  of 
tailorable,  performance  oriented  acquisition  documents  with 
the  SEMS  concept  and  enhanced  RFP/Source  Selection  ac¬ 
tivities  has  put  ASD  back  on  target.  These  activities  form  the 
critical  triad  for  a  more  effective  acquisition  development 
process  which: 

1)  Implements  DoD  direction  while  bringing  a  renewed 
focus  on  satisfying  User  operational  needs. 

2)  Provides  our  contractors  with  a  greater  role  and 
flexibility  to  arrive  at  innovative  designs  which  are  responsive 
to  satisfying  User  needs. 

3)  Provides  the  upfront  communication  of  clear  system 
requirements. 

4)  Focuses  the  technical  evaluation  on  the  proposed 
contractual  documents. 

5)  Utilizes  a  SEMS  to  provide  progress  measurement 
for  enhanced  management  decisions. 

The  Mil-Prime  business  approach  provides  the  process  and 
environment  to  effectively  transgress  the  adversary  relation¬ 
ship  to  form  that  critical  team  partnership  fundamental  to 
successful  development  of  complex  weapon  systems. 
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